Date: Mon, 12 Apr 93 04:30:02 PDT 

From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu> 
Errors-To: Packet-Radio-Errors@UCSD.Edu 

Reply-To: Packet-Radio@UCSD.Edu 

Precedence: Bulk 

Subject: Packet-Radio Digest V93 #97 

To: packet-radio 


Packet-Radio Digest Mon, 12 Apr 93 Volume 93 : Issue 97 


Today's Topics: 
Cable TVI interference (3 msgs) 
fido node regurgitating articles in rec.radio.amateur.* 
GRAPES vs (?) WA4DSY ? 
Is this a valid Belgian call sign? 
rec.radio.amateur reorg/RFD discussion summary 4/11 


Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu> 
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Sun, 11 Apr 1993 18:09:04 GMT 

From: sdd.hp.com! zaphod.mps.ohio-state.edu!wupost!emory!athena!aisun3.ai.uga.edu! 
mcovingt@network.UCSD.EDU 

Subject: Cable TVI interference 

To: packet-radio@ucsd.edu 


You are right -- it's entirely the cable TV company's responsibility to 
keep unwanted signals out of the cable. The cable frequencies are the 
same as frequencies allocated to other things outside the cable. 


If the cable company is picking up unwanted signals, the cable company is 
also _emitting_ unwanted signals (through the same holes), and thus is 
in violation of FCC regulations. 


:- Michael A. Covington, Associate Research Scientist : kK 
:- Artificial Intelligence Programs mcovingt@ai.uga.edu : **kkKKKKK 
:- The University of Georgia phone 706 542-0358 : x * * 


:- Athens, Georgia 30602-7415 U.S.A. amateur radio N4TMI : xx x*k* xk <>< 


Date: Sun, 11 Apr 1993 20:15:14 GMT 
From: n3dmc! johnl@uunet.uu.net 
Subject: Cable TVI interference 

To: packet-radio@ucsd.edu 


Ed Wells (edw@wells.UUCP) wrote: 

It seems to me that the cable TV industry decided to use the same 
: frequencies in the cable that are used as many other ham and/or commercial 
: frequencies outside the cable, and now that leakage/acceptance is occuring, 
: they don't know how to deal with the monster they've created, 
: or their irate customers (who probably are demanding refunds). 


I think the cable company has it backwards (as usual). The cable companies 
were allowed use of frequencies currently allocated to other services 

on the condition that they not cause harmful interference to those 
services and that they accept any interference caused by legitimate 

users of those services. If your friends signal is getting into the local 
cable distribution network it indicates that the cable company is not 
properly maintaining their system. It also means that their cable system 
may be exceeding FCC limits on cable leakage. The FCC has been cracking 
down on cable systems that have excessive leakage, esp. in the aviation 
bands. 

John A. Limpert 

johnl@n3dmc.svr.md.us 

uunet!n3dmc!johnl 


Date: Mon, 12 Apr 1993 05:43:13 GMT 

From: news.acns.nwu.edu!casbah.acns.nwu.edu! lapin@network.UCSD.EDU 
Subject: Cable TVI interference 

To: packet-radio@ucsd.edu 


In article <C5C5LE.IEr@n3dmc.svr.md.us> johnl@n3dmc.svr.md.us (John Limpert) 
writes: 
>Ed Wells (edw@wells.UUCP) wrote: 

It seems to me that the cable TV industry decided to use the same 
frequencies in the cable that are used as many other ham and/or commercial 
frequencies outside the cable, and now that leakage/acceptance is occuring, 
: they don't know how to deal with the monster they've created, 
or their irate customers (who probably are demanding refunds). 


VVVV VV 


>I think the cable company has it backwards (as usual). The cable companies 


>were allowed use of frequencies currently allocated to other services 

>on the condition that they not cause harmful interference to those 
>services and that they accept any interference caused by legitimate 
>users of those services. If your friends signal is getting into the local 
>cable distribution network it indicates that the cable company is not 
>properly maintaining their system. It also means that their cable system 
>may be exceeding FCC limits on cable leakage. The FCC has been cracking 
>down on cable systems that have excessive leakage, esp. in the aviation 
>bands. 

>-- 

>John A. Limpert 

>johnl@n3dmc.svr.md.us 

>uunet !n3dmc!johnl 

> 


John: 


As you stated, the letter of the law is exactly correct. But the original 
post was much more bothersome. If I understood it correctly, the cable 
company understands the law but is trying to use local, neighborhood, 
propoganda to force the ham station off that frequency. 


Also, the original posting mentioned that the FCC had been contacted but 
did not say what happened. 


The original poster asked for reponses via email rather than netnews. I, 
for one, would be very interested in reading the responses and also 
learning what the final disposition of the case is when it happens. 


This is a thread that is ripe for a switch to rec.radio.amateur.policy. I 
hope to see more of it there. 


Greg Lapin, KD9AZ 
glapin@nwu.edu 


Date: Sat, 10 Apr 1993 17:10:23 GMT 

From: valinor.mythical.com!n5ial!jim@uunet.uu.net 

Subject: fido node regurgitating articles in rec.radio.amateur.* 
To: packet-radio@ucsd.edu 


please excuse the cross-posting, but I'm seeing this in all 3 r.r.a groups, 
so in this case, it seems appropriate....my apologies if this isn't a valid 
assumption (but then, the post actually only gets sent once either way, so 
it's not as if it generates any extra net.traffic or anything). 


it would seem that once again, there is a fido node somewhere that seems to 


think that the rest of the world wants to see duplicate copies of every 
Single post. anyone know how to handle this? 


for example, in rec.radio.amateur.policy (when I finally decided I wasn't 
imagining things), I saw a post from greg@core.rose.hp.com (Greg Dolkas). 
a few articles later, guess what....that exact same post is repeated. 
however, this time the article claims to be from 

Greg .Dolkas@f716.n109.z1.his.com (Greg Dolkas). 


the last time I saw this was about a week ago in comp.os.linux, and it 
was a fido node that wasn't configured right, or something like that. 
the symptoms were identical, and just as could quickly become the case 
here, it was no doubt costing a lot of $$$ for some folks (a high-volume 
newsgroup is bad enough...but when someone decides to double that volume 
with duplicate postings, that's *REALLY* bad). 


anyone know how to proceed in getting these duplicates stopped? 


--jim 
d#include <std_disclaimer.h> 73 DE N5IAL (/4) 
INTERNET: jim@n5ial.mythical.com | j.graham@ieee.org ICBM: 30.23N 86.32W 
AMATEUR RADIO: n5ial@w4zbb (Ft. Walton Beach, FL) AMTOR SELCAL: NIAL 


Date: 11 Apr 93 21:20:50 GMT 

From: swrinde! gatech!enterpoop.mit.edu!eru.mt.luth.se!kth.se!lysator.liu.se! 
pme@network.UCSD.EDU 

Subject: GRAPES vs (?) WA4DSY ? 

To: packet-radio@ucsd.edu 


What is the differens ? Or is it the same modem ? Modulation ? 
And where do I get it ? Do I find it at any hamshops ? 
Is there different versions ? And how much do I have to pay ? 


/Petexr SM50HI 


Date: Mon, 12 Apr 1993 05:30:46 GMT 

From: news.acns.nwu.edu!casbah.acns.nwu.edu! Llapin@network.UCSD.EDU 
Subject: Is this a valid Belgian call sign? 

To: packet-radio@ucsd.edu 


In article <jvp.734403143@cpre1.ee.iastate.edu> jvp@vlsi4.ee.iastate.edu (Jim Van 
Peursem) writes: 

> 

>Hi, 

> 

> I was just contacted by a Belgian ham via postal mail. He wrote his 
>call sign as ONL4456. Can this be valid? The ON prefix looks right for 
>Belgium, but a four number suffix? And the length of the call sign is 
>seven characters! How would a call like this work in ax.25 which has 
>room for only six characters plus ssid? Do they run something different 
>than the standard ax.25 in Belgium? 


>| Jim Van Peursem - Ph.D. Student - Ham Radio -> KEOPH 

>| Department of Electrical Engineering and Computer Engineering 
>| Iowa State University - Ames, IA 50011 

>| internet - jvp@iastate.edu -or- jvp@cpre1.ee.iastate.edu 


Jim: 


I have received many cards from Europe with this type of ID. They are 

all SWL cards. Evidently it is very common in Europe to be assigned an SWL 
"License". They compete in listening contests and generally appreciate 
your response that what they have logged was correct. 


73 de Greg KD9AZ 
glapin@nwu.edu 


Date: 11 Apr 93 12:21:36 GMT 

From: rtech!amdahl!amdahl!ikluft@decwrl.dec.com 

Subject: rec.radio.amateur reorg/RFD discussion summary 4/11 
To: packet-radio@ucsd.edu 


This article contains 5 subtopics: 
Current Status of the Discussion 
How to Participate in the Discussion 
Summary of RFD proposed newsgroups (Option I) 
Summary of RFD proposed newsgroups (Option II) 
Notes from the discussion so far 


Current Status of the Discussion 


The RFD (Request for Discussion) for the reorganization of rec.radio.amateur 


was posted on March 26 to news.announce.newgroups, news.groups, and all the 
subgroups of rec.radio.amateur. A summary of the proposed newsgroups can be 
found later in this article. 


We have passed the half-way point in the 30-day discussion period. Current 
tallies of opinions posted to news.groups are as follows: 

in favor: 25 people 93 articles 

opposed: 14 people 30 articles 

undecided or unclear: 10 people 18 articles 
(the "unclear" category only includes replies that were off the subject) 


These numbers may seem small by UseNet standards but it has actually been one 
of the larger of many ongoing discussions on news.groups. Support has been 
running around the 2-to-1 in favor area since the discussion started. Due 

to the support expressed, we expect that it will be possible to issue a CFV 
(Call for Votes) some time after the end of the discussion period, which will 
conclude on April 26, 1993. 


How to Participate in the Discussion 


If you have not yet expressed an opinion on the proposed split, you can make 
it easy on yourself by just replying to this article onto news.groups (the 
Followup-To line already specifies that for you) and say 

I support the reorganization of rec.radio.amateur 
or 

I do not support the reorganization of rec.radio.amateur 


YOUR REPLY MUST BE POSTED TO NEWS.GROUPS IN ORDER TO BE AN OFFICIAL PART OF 
THE NEWSGROUP CREATION PROCESS. You may cross-post to rec.radio.amateur.misc 
if you prefer to. 


It would be even more helpful, if you support the split of r.r.a.misc, to 
indicate which option from the RFD that you prefer. It's OK to say you like 
both. They are summarized below. You can still make things pretty easy for 
yourself by only posting 

I support the reorganization of rec.radio.amateur (Option I) 
or 

I support the reorganization of rec.radio.amateur (Option IT) 
or 

I support the reorganization of rec.radio.amateur (either option) 


Here's a question to ask yourself as you consider these proposals: 
Which proposal would make you more likely to vote for all the newsgroups 
when voting time arrives? (Separate concurrent votes will be held for 
each newsgroup in accordance with the newsgroup creation guidelines. ) 


Summary of RFD proposed newsgroups (Option I) 


(all groups unmoderated) 
Newsgroup name 


rec.radio.amateur.misc 


rec.radio.amateur.policy 
rec.radio.amateur.digital.misc 


rec.radio.amateur.digital.tcp-ip 
rec.radio.amateur.operating 


rec.radio.amateur. products 
rec.radio.amateur.instruction 
rec.radio.amateur.construction 
rec.radio.amateur.space 


rec.radio.amateur.emerg-services 


all Ham radio topics not covered below 
i.e. video, stories, humor, new topics 
[no modification to existing newsgroup] 
regulations & policy issues 

[no modification to existing newsgroup] 
packet radio & other digital modes 
[includes old rec.radio.amateur. packet] 
TCP/IP via packet radio 

Operating procedures and questions: DX, 
CW, contests, propagation, repeaters 
manufactured equipment, modifications 
Ham radio instruction & examination 
homebrewing & experimentation 

amateur radio in space: satellites, 
earth-moon-earth (EME), shuttle, MIR 
emergency services: RACES, ARES, NTS 


Summary of RFD proposed newsgroups (Option II - "the .tech option") 


(all groups unmoderated) 
Newsgroup name 


rec.radio.amateur.misc 


rec.radio.amateur.policy 
rec.radio.amateur.digital.misc 


rec.radio.amateur.digital.tcp-ip 
rec.radio.amateur.operating 


rec.radio.amateur.emerg-services 
rec.radio.amateur.tech 


video 


Notes from the discussion so far 


all Ham radio topics not covered below 
i.e. video, stories, humor, new topics 
[no modification to existing newsgroup] 
regulations & policy issues 

[no modification to existing newsgroup] 
packet radio & other digital modes 
[includes old rec.radio.amateur. packet] 
TCP/IP via packet radio 

Operating procedures and questions: DX, 
CW, contests, propagation, repeaters 
emergency services: RACES, ARES, NTS 
Technical discussions about Ham Radio: 
construction, theory, examinations, 


The following notes may help you determine if any suggestions you are 
considering have already been discussed. Your opinion is important so be 
sure to show your support or opposition and make any suggestions you believe 
would help make this a better, more successful proposal. 


* There has been strong agreement that r.r.a.misc has too much traffic. 

x One of the main points made by those opposing the split has been a concern 
that there may be a lot of cross-posting of articles across the proposed 
newsgroups. 4r.r.a.policy was commonly used as an example. 

* Rebuttal to the cross-posting argument pointed out that even in r.r.a.policy 
there is currently very little cross-posting. With numbers to show this was 
a misconception, one person withdrew opposition and began supporting the 
split. 

*x A point made by proponents of the split was that r.r.a.policy is not a good 
comparison. All the proposed newsgroups were modeled after r.r.a.packet, 
which was made for a subject that many Hams are interested in. r.r.a.policy 
was just a place to throw away an unwanted subject. Still others said that 
r.r.a.policy has plenty of ongoing policy-related discussion and has also 
worked pretty well. 

x On the subject of cross-posting, there has been some discussion about a 
netiquette guide like that found on rec.aviation for the past several years. 
The idea may be considered regardless of the result of the vote. 

x Some concern was expressed by both supporters and opposers about the 
Info-Hams mail list. A common concern was that the mail lists will need to 
match the newsgroups in order for this to work. Comments from Brian Kantor 
indicated a wait-and-see position. He did not rule out making new mail lists 
if the newsgroups pass but he is understandably not enthusiastic since he 
has plenty of other work to do. 

* Two people questioned why the proposal includes making a subhierarchy for 
r.r.a.digital.misc and r.r.a.digital.tcp-ip. It was pointed out that these 
were requested by users of r.r.a.packet due to the explosion of new digital 
modes. There has been no opposition from the r.r.a.packet community. 

* Most people supporting the split have not indicated which option (I or ITI) 
they support. It was noted that it's been difficult to determine which will 
be the most-likely-to-succeed choice to put on the CFV. 

x Those who prefer Option I seem to do so because the newsgroup names are 
clearer and more focused. It was said that r.r.a.tech is too general to 
differentiate itself significantly from r.r.a.misc. So the advantage is 
that Option I avoids some confusion. (Option I adds 7 newsgroups) 

* Those who prefer Option II (r.r.a.tech) seem to do so because it has fewer 
newsgroups than Option I while still offering an area for technical 
discussion away from r.r.a.misc. So the advantage is that Option II is not 
as large an increase in newsgroups. (Option II adds 5 newsgroups) 

x A preference was stated to change r.r.a.products to r.r.a.equipment. 
Rebuttals said that would be confusing next to r.r.a.construction. The 
suggestion did not have enough support to be added to the proposal. 

x A preference was stated to change r.r.a.construction to r.r.a.homebrewing. 
Rebuttals said that the name would not be clear enough to outsiders or 


newcomers. The suggestion did not have enough support to be added to the 
proposal. 

A preference was stated to change r.r.a.operating to r.r.a.dx. Rebuttals 
said this would eliminate coverage for many other aspects of operating 

a radio. (Notably, UHF/VHF repeaters.) Also, this was considered on the 
rra-reorg mail list prior to the RFD, where DX and repeaters were combined 
to make r.r.a.operating. Another suggestion was to add r.r.a.dx alongside 
r.Y¥.a.operating. The suggestion does not appear to have enough support but 
some discussion may continue. 

A preference was stated to add an r.r.a.bulletins newsgroup. No replies 
were made to a subsequent poll on the subject so the suggestion is assumed 
to have insufficient support. One problem was noted that it mostly overlaps 
rec.radio.info which serves all of rec.radio, including rec.radio.amateur.*. 
A couple articles suggested adding an r.r.a.flame newsgroup. Most 
participants seem to have assumed that was said tongue-in-cheek. It has not 
been taken seriously. 

r.Y¥.a.space appears to have significant support. It will probably be on the 
CFV (call for votes) whether Option I or II is selected as the final model. 
It was noted that this will mean that Option II will add 6 newsgroups 
instead of 5. (r.r.a.space was previously only on Option I.) 

A suggestion was made to add an RDF (radio direction finding) newsgroup to 
the proposal. The original suggestion was to call it r.r.a.jamming. Another 
article suggested a clearer name of r.r.a.rdf. An opposing opinion said 
there is not enough traffic to make a separate newsgroup for this topic. 
This subject is not done being discussed but does not yet have enough support 
in the discussion to add it to the proposal. 


Ian Kluft KD6EUI PP-ASEL Amdahl Corporation, Open Systems Development 
ikluft@uts.amdahl.com Santa Clara, CA 
[disclaimer: any opinions expressed are mine only... not those of my employer] 


End of Packet-Radio Digest V93 #97 
KKKKKKKKK KKK KK KKKKKKKKEKKERE KKK 


